Unleash Agility and Mitigate Risk: The Power of Feature Flags

Feature flags are a safe and easy way to include non-finished code in production rollouts. They allow us to change the behavior of the software in production without the need for additional code rollouts.

But why would you do that?

🚀 lets us move faster, as they enable trunk-based development avoiding merge hell
✅ allows us to verify a feature on production without enabling it for all users
🆘 allows us to switch off a newly introduced feature immediately in case of issues
🔗 allows us to decouple rollouts if a feature spans over multiple services and teams

These characteristics make feature flags a valuable tool in the Agile Developer’s tool belt.

They come with some disadvantages though.

📉 every feature flag is tech debt and needs to be removed as soon as the feature is stable
🔄 reusing feature flag ids can cause old code to be executed if the cleanup didn’t happen and hence can cause unpredictable behavior
🧠 higher complexity of the system with each feature flag added
👷 higher effort as additional tests have to be written to make sure, the system behaves as expected in all feature flag states

eBay supports the OpenFeature project of the Cloud Native Computing Foundation and adopted the OpenFeature specification as their client interface. This also gave me the opportunity to contribute to the OpenFeature Java SDK and give back a little to the community.

The main advantages of using OpenFeature:

📖 low learning curve for engineers when onboarding to a new company which uses OpenFeature
🔂 the ability to change the feature flag management system, without changing the client code. This enables assessing different solutions, in-house solution or different external vendors and a smooth transition to a different flag management system.

Learn more about the Open Feature Project.

Did you already adopt feature flags? What downsides do you see?

Let's discuss!

Please let's discuss on LinkedIn.